Symptom

#105104: clicking a bot in the roster intermittently does nothing. No backend activity, then a "try again" toast. On the same 3-slot local pool, the first send on a fresh chat and "New session" / tab-strip "+" could wait out the background slot timeout while roster hydration held every slot.

What was happening, per layer

#102281 / #104139 tagged the activation doors (openGatewayForAgent, openGatewayForProfile, ensureGatewayForAgent, sharedPrimaryRoute) as foreground, and 5eb0ed4531 gave requestGatewayForProfile a { spawnPriority } options object. Two RPC paths never got it:

• apps/desktop/src/store/gateway.ts:1026 requestGatewayForAgent and :1229 retainGatewayForAgent had no priority parameter. Their isAttachedSharedRemote probe, openSecondary connect, and both requestGatewayForProfile forwards dialed background. retainGatewayForAgent's plain-profile branch (gatewayForProfile(key, true)) too; neither salvaged PR covered that one.
• apps/desktop/src/app/session/hooks/use-session-actions/index.ts:604,612 (createBackendSessionForSend) and :824,832 (openNewSessionTile) are the only callers of that pair for a session create, and they passed nothing.
• apps/desktop/src/plugins/hermes-bots/canonical-chat.ts:245 requestForBot(bot, 'session.list') -> routing.ts:213 host.requestProfile(route, method, params) -> sdk/index.ts:249 requestGatewayForAgent(...). The click's first RPC, the one that cold-spawns the bot's backend, carried no intent. The later host.openSession is already foreground but never runs until this lookup returns.

Fix, per layer

• gateway.ts: requestGatewayForAgent(..., timeoutMs?, signal?, { spawnPriority = 'background' } = {}) and retainGatewayForAgent(connectionId, profile, { spawnPriority = 'background' } = {}), same options shape as requestGatewayForProfile. Forwarded into both requestGatewayForProfile branches, isAttachedSharedRemote, openSecondary, and gatewayForProfile(key, true, spawnPriority). SpawnPriority is exported for the SDK.
• use-session-actions/index.ts: the four create-path calls pass { spawnPriority: 'foreground' }; the retain is the first dial so it carries the tag too.
• sdk/index.ts: host.requestProfile(route, method, params, timeoutMs?, options?: { spawnPriority }). timeoutMs stays positional so no existing caller changes shape, and the SDK keeps its exact call arity when options are absent (the pool tests pin that). JSDoc on requestProfile documents the choice.
• hermes-bots/routing.ts: requestForBot(bot, method, params, options?) forwards spawnPriority only when set. canonical-chat.ts: the canonical session.list and the session.create on a first-ever open pass 'foreground'. Passive roster warming (profiles.list, ui_meta) still dials background.

Tests

Both polarities at each layer, converted from the PRs' change-detectors into behaviour contracts:

• store/gateway-spawn-priority.test.ts: request/retain tagged -> every registry dial carries priority: 'foreground'; untagged -> no priority key; retain on the plain-profile (null connection) route dials foreground.
• sdk/profile-routing.test.ts: options form with a timeout and without one; the existing numeric-timeout and no-timeout tests still pin the old arity.
• plugins/hermes-bots/routing.test.ts: tag forwarded as the fifth arg; an untagged call keeps three args.
• plugins/hermes-bots/canonical-chat-registry.test.ts: session.list and session.create carry the tag, session.title does not.
• use-session-actions.test.tsx, default-new-session.test.tsx: create matchers pin the tagged dial and the tagged retain.

Red on base: with the five production files stashed and the tests kept, 9 failed / 187 passed across the five touched test files (all nine are the new foreground assertions; the negative-polarity tests pass on base as expected). Green after: 196/196. npx vitest run src/store src/sdk src/plugins/hermes-bots src/app/session: 3173 passed, the 2 failures are voice-prefs.test.ts, pre-existing on main. npm run typecheck clean; npx eslint on the touched files: 0 errors.

Not fixed here

• Pool lifetime leases / reclaiming an idle background slot for a foreground dial: that is the fix(desktop): reclaim idle pool backend for foreground dials (#102281 follow-up) #104871 cluster, being salvaged separately. This PR only makes sure the user's dial asks for the reserved slot; it does not change how the pool hands one out.
• The launchd token loop (fix(launchd): park EX_CONFIG token conflicts instead of KeepAlive-looping #112079) is a different bug and already merged.
• No Closes #105104: this is one layer of that symptom.

Supersedes #110354, #105390.

Thanks @jxfjosh: the diagnosis that the canonical lookup's session.list is the click's first dial, and that it had to go through host.requestProfile, is the centre of the second commit. Thanks @nftpoetrist: the observation that requestGatewayForAgent / retainGatewayForAgent were the one untagged dial pair left after #102281, and that the retain must be tagged as well as the create, is the first commit. Both are credited as commit authors.